Decoupling Matrix creation from Application#5185
Conversation
…low us to inject a consistent instance
allows the matrix configuration to also contain dependencies
…uld also be backed back the test module instead of the singleton state
…y calling getInstance
|
|
||
| @Provides | ||
| fun providesMatrix(context: Context): Matrix { | ||
| fun providesMatrixConfiguration(context: Context): MatrixConfiguration { |
There was a problem hiding this comment.
extra dependencies can be added here, such as the VectorFeatures!
| } | ||
| } | ||
|
|
||
| override fun providesMatrixConfiguration(): MatrixConfiguration { |
There was a problem hiding this comment.
the main downside to using MatrixConfiguration.Provider is that it occurs during super.onCreate which means the dependencies declared in the application haven't been injected yet, making the object creation lifecycle a bit misleading
Matrix SDKIntegration Tests Results:
|
| fun providesMatrixConfiguration(context: Context): MatrixConfiguration { | ||
| return MatrixConfiguration( | ||
| applicationFlavor = BuildConfig.FLAVOR_DESCRIPTION, | ||
| roomDisplayNameFallbackProvider = VectorRoomDisplayNameFallbackProvider(context) |
There was a problem hiding this comment.
We could probably also provide RoomDisplayNameFallbackProvider as a param.
| @HiltAndroidApp | ||
| class VectorApplication : | ||
| Application(), | ||
| MatrixConfiguration.Provider, |
There was a problem hiding this comment.
Maybe delete this interface? Or can it still be used by other application?
There was a problem hiding this comment.
it could be used by other clients of the SDK, if we agree that the Matrix singleton API should avoid querying the application then we could mark the interface as deprecated and schedule removing it? potentially with some migration steps~
what do you think?
There was a problem hiding this comment.
Yes I think we should remove this and the inner singleton to avoid mistakes!
Regarding the process, we could indeed mark them as deprecated in a first place.
| @Singleton | ||
| fun providesMatrix(context: Context, configuration: MatrixConfiguration): Matrix { | ||
| Matrix.initialize(context, configuration) | ||
| return Matrix.getInstance(context) |
There was a problem hiding this comment.
Will this work since the context is not implementing MatrixConfiguration.Provider anymore?
There was a problem hiding this comment.
Ah, just read again the description, sorry
There was a problem hiding this comment.
no worries! yep it'll work but... it's only because of the exact order of these calls
initialise() // sets the private singleton instance
getInstance() // the instance is not null so we avoid attempting to read from (application as Provider). providesMatrixConfiguration()
I could add another documented function to the companion object to only create an instance without making use of the internal singleton (in our case dagger/hilt will handle the singleton instance for us)
/**
* Creates an instance of Matrix, it's recommend to manage this instance as a singleton.
* To make use of the built in singleton use Matrix.initialise() or Matrix.getInstance(context) instead
**/
fun createInstance(context: Context, matrixConfiguration: MatrixConfiguration) : Matrix {
return Matrix(context.applicationContext, matrixConfiguration)
}
There was a problem hiding this comment.
I did it 😄 having the separate method really helps clarify the ambiguity fd2d928
Matrix.initialize and Matrix.getInstance are now unused in Element
…non singleton/duplicated singleton usages - also documents the static methods
matrix-sdk-android/src/main/java/org/matrix/android/sdk/api/Matrix.kt
Outdated
Show resolved
Hide resolved
| @HiltAndroidApp | ||
| class VectorApplication : | ||
| Application(), | ||
| MatrixConfiguration.Provider, |
| private val vectorFileLogger: VectorFileLogger, | ||
| private val systemLocaleProvider: SystemLocaleProvider | ||
| private val systemLocaleProvider: SystemLocaleProvider, | ||
| private val matrix: Matrix |
| /** | ||
| * Either provides an already initialized singleton Matrix instance or queries the application context for a MatrixConfiguration.Provider | ||
| * to lazily create and store the instance. | ||
| */ |
There was a problem hiding this comment.
Maybe update the comment at line 132 ("You should call Matrix.initialize or let your application implements MatrixConfiguration.Provider.") to inform developers that they can manage the singleton themselves by using createInstance
matrix-sdk-android/src/main/java/org/matrix/android/sdk/api/Matrix.kt
Outdated
Show resolved
Hide resolved
…trix.kt Co-authored-by: Benoit Marty <benoitm@matrix.org>
…trix.kt Co-authored-by: Benoit Marty <benoitm@matrix.org>
… in favour of clients controlling their own instances
…tor-im/element-android into feature/adm/decouple-matrix-creation
Decouples the creation of our
Matrixinstance from the application by using the DI factory instead.This has the benefit of allowing the
MatrixConfigurationto use injectable dependencies.Matrix.getInstance, we're now advocating for clients to create and maintain their own singletons instead, instances ofMatrixcan be created withMatrix.createInstance